-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Navigation Screen: Update sidebar #31821
Conversation
Size Change: +830 B (0%) Total Size: 1.62 MB
ℹ️ View Unchanged
|
I had few more changes in mind, mostly code quality, but decided to create separated PRs for an easy review process. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for catching this, @getdave The issue should be fixed now. Screenshot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for tackling this PR.
I can't decide about this one. On one hand it's great to have a space to put settings that are Navigation Editor specific rather than relying on filtering the core/navigation
block to ad what we need.
On the other hand by never showing the core/navigation
block's inspector controls we going to end up losing a lot of settings that come "out of the box" with the block.
Is there a way we can get the best of both world's? Looks like @shaunandrews had some good ideas with tabs in #30325 (comment).
This would make the screen a kin to the post editor where you have the idea of the "Post" and the "Block". We could have "Navigation" and "Block", defaulting to "Block".
If we want to auto select the core/navigation
block when nothing is selected we can do akin to:
const { selectedBlock, allBlocks } = useSelect( ( select ) => {
return {
selectedBlock: select( blockEditorStore ).getSelectedBlock(),
allBlocks: select( blockEditorStore ).getBlocks(),
};
}, [] );
const { selectBlock } = useDispatch( blockEditorStore );
useEffect( () => {
if ( null === selectedBlock && allBlocks?.length ) {
selectBlock( allBlocks[ 0 ].clientId );
}
}, [ selectedBlock, allBlocks ] );
Ultimately should we try to:
- Mirror patterns already established in the Post/Site Editor.
- Avoid losing the Block sidebar that comes with the
core/navigation
block.
I like the idea.
I think it makes more to have "Navigation" selected by default. This is where general navigation settings will live. Going to start working on updates. |
@getdave, the second iteration is ready for testing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✅ This is a big improvement. There's now a clear distinction between the blocks and the wider concept of the menu. It also allows us to decouple controls that are unique to the Editor from the core/navigation
block.
I tested this with various scenarios and couldn't find any obvious errors.
🚢 👏 👏 👏 👏
d6bea7c
to
56808ca
Compare
56808ca
to
00c1cad
Compare
👏 👏 👏 👏 |
Description
Updates sidebar to incorporate tabs for Menu and Block settings, as suggested by @shaunandrews #30325 (comment).
New design and UX are similar to sidebars of other editor screens.
Changes look a lot, but it's mostly moving components into a new directory.
Fixes #30325.
Fixes #31508.
How has this been tested?
Screenshots
CleanShot.2021-05-18.at.15.18.51.mp4
Types of changes
New feature
Checklist:
*.native.js
files for terms that need renaming or removal).